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Sir/Madam: 

Further to the Notice of Appeal filed November 15, 2004, Appellants present this 
Appeal Brief Appellants respectfully request that the Board of Patent Appeals and 
Literferences consider this appeal. 
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I, REAL PARTY IN INTEREST 



As evidenced by the assignment recorded at Reel 01 1078, Frame 0116, the subject 
appHcation is owned by Sun Microsystems, Inc., a corporation organized and existing 
under and by virtue of the laws of the State of Delaware, and now having its principal 
place of business at 4150 Network Circle, Santa Clara, CA 95054. 

II. RELATED APPEALS AND INTERFERENCES 

No other appeals, interferences or judicial proceedings are known which would be 
related to, directly affect or be directly affected by or have a bearing on the Board's 
decision in this appeal. 

III. STATUS OF CLAIMS 

Claims 1-51 are pending. Claims 1-5, 13-22, 30-39 and 47-51 are rejected. 
Claims 6-12, 23-29 and 40-46 are objected to but otherwise allowable if rewritten in 
independent form. The rejection of claims 1-5, 13-22, 30-39 and 47-51 being appealed. 
A copy of claims 1-5, 13-22, 30-39 and 47-51 is included in the Claims Appendix herein 
below. 

IV. STATUS OF AMENDMENTS 

No amendments to the claims have been submitted subsequent to the final 
rejection. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Traditional networks are complex to set up, expand and manage. For example, 
adding hardware or software to a network often requires a network administrator to load 
drivers and configure systems. Making small changes to a network configuration may 
require that the entire network be brought down for a period of time. Also, certain 
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intelligent devices may not support the necessary interfaces to communicate on a given 
network. The computing landscape is moving toward a distributed, Web-centric service 
and content model where the composition of client services and content changes rapidly. 
It would be desirable for such devices to be able to communicate and share resources with 
more powerful devices as well as thinner or less powerful devices. Also, with the advent 
of the Litemet and resulting explosion of devices connected to the net, a distributed 
programming model designed to leverage this phenomenon is needed. Various cUents 
from thick to thin and services need to be connected over the hitemet, corporate hitemets, 
or even within single computers. 

Claim 1 is directed to a method for accessing a service in a distributed computing 
environment. As described on page 112 of the specification, a cHent may receive a 
capability credential that indicates that the client is allowed to access a portion of a first 
service's capabilities {see also, e.g., FIGs. 41 and 43; page 13, lines 21-30; page 14, line 
29 - page 15, line 3; page 107, lines 18-23; page 108, lines 1-9; page 112, lines 8-21; 
page 114, lines 13-23; and page 116, lines 11-25). The client may use the capability 
credential to request an access interface document to access the first service, for example, 
as described on page 108, lines 1-26 and page 15, lines 3-13 of the specification. After 
requesting an access interface document, the client may receive the access interface 
document which contains an interface for accessing only the portion of the first service's 
capabilities (see, e.g., page 15, lines 5-13; FIG. 41, 43; page 108, lines 1-26; and page 
112, lines 8-27). 

Once the client has obtained the access interface document, as described above, 
the client may use the interface from the access interface document to access a capability 
from the portion of the first service's capabilities (see, e.g., FIG. 41; page 113, lines 8-21; 
and page 116, line 18 - page 117, line 2). 

Claim 18 is directed to a client device (see, e.g., page 46, lines 10-20; page 122, 
lines 23-26) including a connection to a distributed computing environment (see, e.g. 
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page 22, lines 5-30; page 24, lines 18-30) and an interface coupled to the connection and 
configured to receive over the connection a capability credential. The capability 
credential indicates that a client on the client device is allowed to access a portion of a 
first service's capabilities. Please refer to the summary of claim 1, above, for more 
details regarding the receiving of a capability credential indicating that a client is allowed 
to access a portion of a service's capabilities. 

Similar to the method recited in claim 1, and summarized above, the interface of 
client device of claim 18 may be configured to use the capabihty credential to request an 
access interface document to access the first service. See, e.g., page 108, lines 1-26 and 
page 15, lines 3-13. 

Additionally, the interface may be configured to receive the access interface 
document over the connection and the access interface document may contain 
information for accessing only the portion of the first service's capabilities. The interface 
may also be configured to use the information from the access interface document to 
access over the connection a capability from the portion of the first service's capabilities. 
Please refer to the summary of claim 1 above for more information regarding the access 
interface document. 

Claim 35 is directed to a carrier medium (see, e.g., page 166, line 30 - page 167, 
line 5) including program instructions computer-executable on a client device, such as the 
cHent device recited by claim 18, for example. The program instructions recited in claim 
35 are configured to implement functionality similar to the method recited in claim 1, 
discussed above. Please refer to the discussion of claim 1 above for more information. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Claims 1, 18 and 35 under 35 U.S.C. § 102(e) as being anticipated by He 
et al. (U.S. Patent 6,088,451) (hereinafter "He"). 
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2. Claims 2-5, 13-17, 19-22, 30-34, 36-39 and 47-51 stand finally rejected 
under 35 U.S.C. § 103(a) as being unpatentable over He in view of PuUiam et al. (U.S. 
Patent 6,609,108) (hereinafter "PuUiam"). 



VII. ARGUMENT 

First Ground of Reiection : 

Claims 1,18 and 35 are rejected under 35 U.S.C. § 102(e) as being anticipated by 
He. Appellants traverse this rejection for at least the following reasons. Different groups 
of claims are addressed under their respective subheadings. 

Claim 1 ; 

Regarding claim 1, He fails to anticipate a client using a capability credential to 
request an access interface document to access a service, the cHent receivins the access 
interface document , wherein the access interface document comprises an interface for 
accessing onlv a portion of the service's capabilities , and the client using the interface 
from the access interface document to access a capability from the portion of the service's 
capabilities. Instead, He presents a system for securing access to network elements by 
user elements (He, Abstract). He teaches a hierarchy of tickets used for access control. 
He also teaches controlling access to network elements through the use of an 
authentication server, a credential server and a network element access server (He, 
column 2, lines 12-16). He does not disclose anything regarding an access interface 
document comprising an interface for accessing only a portion of a service's capabilities, 
as the Examiner erroneously contends. The He reference is not concemed with access 
interface documents by which a client accesses a service. The access control credentials 
and tickets, such as He's general and session tickets, are used only for access control, not 
as interface documents. 
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He also fails to anticipate a client using a capability credential to request an 
access interface document to access a service. The Examiner cites column 20, line 14 
through column 21, line 22 of He; however, Appellants note that this passage describes 
He's ticket system in v^hich a user presents a general ticket obtained from a credential 
server to a network element access server to receive a session ticket (He, column 20, lines 
16 -19). Thus, the Examiner seems to be arguing that He's session ticket is an access 
interface document. However, He teaches that a general ticket, provided to a user during 
login, is used to obtain a session ticket that includes a unique session encryption key (He, 
column 2, lines 36-51). He's session ticket is certainly not an interface document and 
obtaining a session ticket cannot be considered requesting an access interface document. 
Nowhere does He disclose anything regarding a client using a capability credential to 
request an access interface document to access the first server. No requested credential 
or ticket in He is an access interface document comprising an interface for accessing only 
a portion of the service's capabilities. In fact, He explicitly teaches that a session ticket 
"is encrypted using a key derived from the password of the selected network element so 
that only the selected network element can verify the session ticket" (He, column 2, lines 
51-55). He's session ticket is simply an authentication credential used by network 
elements to verify the user. 

Further regarding claim 1, He also fails to teach the client receiving the access 
interface document , wherein the access interface document comprises an interface for 
accessing only said portion of the service's capabilities. The Examiner cites column 26, 
lines 58-65 of He, describing how a user (of He's system) selects a network element to 
communicate with via one or more pull-down menus. The Examiner further argues that 
He's pull-down menus are an access interface documents. Firstly, the Examiner seems to 
be arguing that both He's session ticket (as discussed in the paragraph above) and He's 
pull-down menus are access interface documents. It is clearly improper for the Examiner 
to use two disjoint interpretations of He in combination in his rejection. The Examiner is 
clearly attempting to combine disparate teachings from He to piece together Appellants' 
invention in hindsight. 
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Furthermore, the pull-down menus of He are not access interface documents, but 
are simply a mechanism by which a user may select a particular network element. The 
Examiner contends that when a user of He's system is given access to pull down menus 
to identify network elements, a client is receiving an access interface document that 
comprises an interface for accessing only a portion of a service's capabilities. However, 
He actually teaches that the user may use the pull down menus to make an access request 
for a particular network element (He, column 26, lines 60-62). Allowing a user to access 
pull down menus to select a desired network element does not constitute receiving an 
access interface document. The pull-down menus of He only allow a user to select a 
particular network element and do not comprise an interface for accessing only a portion 
of a service's capabilities, as the Examiner suggests. He uses pull-down menus only in 
their traditional use as user interface elements to select a specific entry. No one of 
ordinary skill in the art would interpret such pull down menus as an access interface 
document. He does not mention anything about receiving an access interface document, 
nor about the use of pull down menus involving any access interface document 
comprising an interface for accessing a portion of a service's capabilities. The Examiner 
has not shown any teaching in He that discloses receiving an access interface document as 
recited in claim 1 . 

The Examiner also asserts that a user (in He's system) using a pull down menu to 
make an access request corresponds to a client using the interface from the access 
interface document to access a capability from said portion of the first service's 
capabilities. Appellants disagree with the Examiner's interpretation of He. He teaches 
that once the user selects a desired network element through a pull down menu, the user 
element local access control system sends an access request to the network security server 
that "returns a session ticket to the user element for communicating with the selected 
network element" (He, column 27, lines 40-47). The Examiner argues that obtaining a 
session ticket in He equates to requesting an access interface document and that selecting 
a network element (from a pull down menu) in order to obtain a session ticket 
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corresponds to using the access interface document. However, according to He, a user 
first selects a network element and only then requests a session ticket for that network 
element. The Examiner contends that He's use of a general ticket to receive a session 
ticket corresponds to the element in claim 1 of the client using a capability credential to 
request an access interface document to access the first service, and the Examiner further 
contends that He's use of a pull down menu corresponds to the elements in claim 1 of the 
client receiving the access interface document and using the interface from the access 
interface document to access a capability from said portion of the first service's 
capabilities. However, as discussed above, He clearly teaches that a user uses the pull 
down menu (which the Examiner equates to using an interface from an access interface 
document to access a capability from a portion of a service's capabilities) to first select a 
network element for which a user then obtains a session ticket (which the Examiner 
equates to requesting an access interface document). Li contrast, claim 1 recites that a 
user requests an access interface document and then uses the interface from the received 
access interface document to access a capability from a portion of a service's capabilities. 
Thus, not only is the Examiner's interpretation of He illogical, but when claim 1 is 
considered in its entirety the teachings of He cannot possibly correspond to the 
combination elements as related in the claim. 

Further, He describes how a session ticket includes a unique session encryption 
key. Thus, when the user selects a network element, the user is actually performing an 
authentication fimction by presenting a general ticket in order to obtain" a session 
encryption key with the session ticket. Hence, He teaches that a user selects a specific 
network element from a pull down menu to request a session ticket and encryption key to 
allow fixture access to the network element. Neither a session ticket nor an encryption 
key can be considered an access interface document. Neither includes any interface 
information. Instead, they are simply security control mechanisms. He does not describe 
requesting a session ticket as using an interface from an access interface document to 
access a capability from a portion of a service's capabilities. 
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Anticipation requires the presence in a single prior art reference disclosure of each 
and every element of the claimed invention, arranged as in the claim . M.P.E.P 2131; 
Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 
485 (Fed. Cir. 1984). The identical invention must be shovra in as complete detail as is 
contained in the claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). He does not teach a client using a capability credential to request an access 
interface document to access a service, the client receiving the access interface document , 
wherein the access interface document comprises an interface for accessing only a portion 
of the service's capabilities , and the cHent using the interface from the access interface 
document to access a capability from the portion of the service's capabilities. Thus, He 
clearly does not anticipate claim 1 . 

Claim 18 ; 

Regarding claim 18, He fails to disclose a client device including an interface 
configured to use the capability credential to request an access interface document to 
access the first service. Instead, He presents a system for securing access to network 
elements by user elements (He, Abstract). Nowhere does He describe using a capabiUty 
credential to request an access interface document. The Examiner cites column 20, line 
14 through column 21, line 22 of He, hov^ever this passage describes He's ticket system 
in which a user presents a general ticket obtained firom a credential server to a network 
element access server to receive a session ticket (He, column 20, lines 16 -19). He's 
access control credentials and tickets, such as the general and session tickets, are used 
only for access control, not as access interface documents. Please refer to the discussion 
of claim 1 above for more details regarding He's failure to anticipate using a capability 
credential to request an access interface document. 

Further regarding claim 18, He fails to anticipate wherein the interface is further 
configured to receive the access interface document over the connection, wherein the 
access interface document comprises information for accessing only said portion of the 
first service's capabilities . As discussed above regarding claim 1, the Examiner argues 
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that He discloses receiving an access interface document by teaching how a user may gain 
access to pull down menus in order to choose a specific network element with which to 
communicate. However, the pull-down menus of He are not access interface documents, 
but are merely a mechanism by which a user may select a particular network element. 
The Examiner contends that when a user of He's system is given access to such pull 
down menus to identify network elements, a client is receiving an access interface 
document that comprises an interface for accessing only a portion of a service's 
capabilities. He, however, teaches that the user may use the pull down menus to make an 
access request for a particular network element (He, column 26, lines 60-62). Allowing a 
user to access pull down menus to select a desired network element does not constitute 
receiving an access interface document. He does not disclose anything regarding an 
access interface document comprising an interface for accessing only a portion of a 
service's capabilities, as the Examiner contends. 

Please see the remarks above regarding claim 1 for a more detailed discussion 
regarding the Examiner's interpretation of He's pull down menus. 

He further fails to disclose wherein the interface is further configured to use the 
information from said access interface document to access over the connection a 
capabilitv from said portion of the first service's capabilities. The Examiner asserts that a 
user (in He's system) using a pull down menu to make an access request corresponds 
using the information fi^om the access interface document to access a capability from said 
portion of the first service's capabilities. However, the pull-down menus of He only 
allow a user to select a particular network element and do not comprise an interface for 
accessing only a portion of a service's capabilities, as the Examiner suggests. He uses 
pull-down menus only in their traditional use as user interface elements to select a 
specific entry. Please refer to the discussion above regarding claim 1 for a detailed 
argument regarding the Examiner's interpretation of He's use of session tickets and pull 
down menus. 
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Thus, for at least the reasons give above, He clearly does not anticipate a client 
device comprising an interface configured to use a capability credential to request an 
access interface document to access a service; wherein the interface is also configured to 
receive the access interface document, wherein the access interface document comprises 
information for accessing only the portion of the service's capabilities indicated by the 
capability credential and wherein the interface is further configured to use the information 
form the access interface document to access over the connection a capability from the 
portion of the service's capabilities. 

Claim 35 : 

Regarding claim 35, He fails to anticipate receiving a capability credential 
wherein said capability credential indicates that a client within the client device is 
allowed to access a portion of a first service's capabilities , histead. He presents a system 
for securing access to network elements by user elements (He, Abstract). A more 
detailed description of He's teachings is presented above regarding claim 1. He is not 
concerned with access interface documents by which a client accesses a service. The 
access control credentials and tickets, such as He's general and session tickets, are used 
only for access control, not as access interface documents. 

He additionally does not teach using the capability credential to request an access 
interface document to access the first service. The Examiner cites column 20, line 14 
through column 21, line 22 of He; however Appellants note that this passage describes 
He's ticket system in which a user presents a general ticket obtained from a credential 
server to a network element access server to receive a session ticket (He, column 20, lines 
16 -19). Please refer to the discussion of claim 1, presented above, for a detailed 
argument regarding He's failure to anticipate using a capability credential to request an 
access interface document. 

Further regarding claim 35, appellants submit that He also fails to teach the client 
receiving the access interface document , wherein the access interface document 
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comprises an interface for accessing only said portion of the first service's capabilities. 
The Examiner argues that He discloses a client receiving an access interface document by 
teaching how a user may gain access to pull down menus in order to choose a specific 
network element with which to communicate. However, the pull-down menus of He are 
not access interface documents, but are merely a mechanism by which a user may select a 
particular network element. He does not disclose anything regarding an access interface 
document comprising an interface for accessing only a portion of a service's capabilities, 
as the Examiner contends. 

The remarks above, regarding claim 1, provide a detailed argument rebutting the 
Examiner's interpretation of He's teachings regarding receiving and using an access 
interface document. Li short, He does not mention anything about receiving; an access 
interface document, nor about the use of pull down menus involving any access interface 
document comprising an interface for accessing a portion of a service's capabilities. The 
Examiner has not shown any teaching in He that discloses the receiving of an access 
interface document. 

Second Ground of Rejection : 

Claims 2-5, 13-17, 19-22, 30-34, 36-39, 47-5 are rejected under 35 U.S.C. § 
103(a) as being unpatentable over He in view of PuUiam. Appellants traverse this 
rejection for the following reasons. Different groups of claims are addressed under their 
respective subheadings. 

Claims 2, 3, 19. 20. 36 and 37 : 

Regarding claim 2, He in view of PuUiam fails to teach wherein using a capability 
credential to request an access interface document comprises sending an advertisement 
request message in a data representation language , wherein the advertisement request 
message includes the capability credential. The Examiner recognizes that He fails to 
teach sending an advertisement request message in a data representation language, and 
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relies upon Pulliam to disclose this functionality. PuUiam teaches an online shopping 
communication schema for communication online shopping orders such as vehicle orders 
(Pulliam, Abstract) and has nothing to do with a cUent requesting an interface document 
comprising an interface usable by the cUent to access only a portion of a service's 
capabilities. 

PulUam teaches that a client may request a list of identifier and value pairs for a 
number of criteria and may use the returned values to populate pull-down lists of 
available automobile makes and models (Pulliam, column 13, lines 31-37)., The 
Examiner holds that such pull-down lists are an access interface document to access the 
available makes and models. Appellants disagree. PulUam never mentions anything 
regarding an access interface document, nor about using such pull-down lists as an access 
interface document that comprises an interface for accessing a portion of a service's 
capabilities , hi contrast, Pulliam teaches that the client uses the pull-down lists and a 
user's selections among the pull-down lists to compile an XML message "that requests a 
list of matching vehicles in inventory database 612" (Pulliam, column 13, lines 37-49). 
Thus, rather than being an access interface document as the Examiner contends, the pull- 
down lists, and the data that make up such lists, are clearly just search criteria, and 
therefore just data, to be sent as part of a database search request. 

Additionally, PulUam fails to disclose anything regarding sending an 
advertisement request message. The searching of an online automobile database 
according to user specified search criteria in Pulliam has nothing to do with an 
advertisement request message. The Examiner's cited passages (PuUiam, column 14, 
lines 34-45, and column 15, lines 38-42) refer only to a locate server that uses PKI 
encrypted user credentials to provide access control. Neither of these passage teaches 
anything regarding sending an advertisement request message. Moreover, even through 
Pulliam teaches the use of XML to describe the search criteria and the corresponding 
search results (Pulliam, column 13, lines 25-29), Pulliam fails to teach sending an 
advertisement request message in a data representation language. Appellants submit that 
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sending an advertisement request message is very different than sending search criteria 
and search result messages in XML. Just because XML is a data representation language, 
does not mean that using XML for search criteria or search result messages corresponds 
to or suggests sending an advertisement request message in a data representation 
language. 

Furthermore, Appellants submit that the proposed combination of He and PuUiam, 
as suggested by the Examiner, would not result in any system that includes sending an 
advertisement request message in a data representation language as part of using a 
capability credential to request an access interface document. Instead, such a 
combination would result in an online automobile search system that uses He's general 
and session security tickets to obtain authorization for user searches of available vehicles. 
Since both He and Pulliam fail to teach anything regarding using a capability credential to 
request an access interface and both also fail to disclose sending an advertisement request 
message in a data representation language, the proposed combination of He and Pulliam 
would not include such features. 

In the Response to Arguments section of the Final Office Action, the Examiner 
states, "one cannot show nonobviousness by attacking the references individually where 
the rejections are based on combination of references," However, Appellants have clearly 
shown that even if He's system was modified so that a user requested a ticket by sending 
a request message in a data representation language, the request would still be for just a 
ticket, not an interface document comprising an interface usable by the client to access 
only a portion of a service's capabilities (See Response dated June 28, 2004, page 14, 
lines 10-13). 

In the Response to Arguments section of the Advisory Action, the Examiner 
asserts that He in view of Pulliam teaches generating a custom advertisement in response 
to receiving an advertisement request message, and refers to Appellants' claim 2. 
However, none of the Examiner' arguments refer to any limitation recited in claim 2. 
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Thus, the Examiner has failed to 1) provide any specific argument, 2) cite any portion of 
He or Pulliam that teaches or suggests the hmitations of claim 2, or 3) provide any 
specific rebuttal to the arguments above (when presented previously) regarding claim 2. 

Claim 4 : 

Regarding claim 4, He in view of Pulliam does not teach generating a custom 
advertisement in response to receiving the advertisement request message. Additionally, 
He in view of Pulliam fails to disclose that the custom advertisement is generated 
according to the portion of the service's capabilities that the capabihtv credential 
indicates the client is allowed to access, and sending an advertisement request response 
message to the client, wherein the advertisement request response message includes the 
custom advertisement as the access interface document . 

The Examiner argues that, "the server [in He] generates pull-down menus to 
identify those capabilities to which the client is allowed/authorized to access" (emphasis 
added) citing He, column 26, lines 58-65 and Pulliam, column 13, lines 34-40). 
However, the pull-down menus in He and Pulliam referred to by the Examiner have 
nothing to do with generating a custom advertisement as an access interface document 
according to the portion of the service's capabilities that the capability credential 
indicates the client is allowed to access. He's pull down menus "identify those network 
elements to which [the user] is allowed access." The cited passage of Pulliam pertains to 
"pull-down lists of available makes and models" which may be used to select 
"preferences" for "matching vehicles" as described above regarding claim 2. Pulliam' s 
teachings have nothing to do with generating a custom advertisement according to a 
portion of a service's capabilities. 

Furthermore, the Examiner refers to He's and Pulliam's pull-down menus as 
identifying capabilities. He, however, does not teach using pull-down menus to identify 
capabilities, but instead uses pull-down menus to identify those specific network 
elements with which a user may communicate (He, column 26, lines 58-65), not any 
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particular capabilities or portions of the capabilities of a service that a user may access. 
Similarly, PuUiam never describes puU-dov^n menus as identifying service capabilities. 
Instead, Pulliam uses pull-dow^n lists as one example of collected search criteria from a 
user (PuUiam, column 13, lines 34-37). The Examiner is clearly applying his own 
hindsight-based speculation to the teachings of He and Pulliam. 

hi his Response to Arguments section of the Advisory Action, the Examiner refers 
to PuUiam' s lists of makes and models of available automobiles as a custom 
advertisement generated in response to a receiving an advertisement request message. 
However, Pulliam is referring to search results generated in response to user input 
specifying desired search criteria (PuUiam, column 15, lines 21-39). Furthermore, neither 
He, nor Pulliam mentions anything regarding sending an advertisement request response 
message to the client, wherein the advertisement request response message includes the 
custom advertisement as the access interface document. Instead, He teaches the creation 
of pull-down menus allowing a user to select a network element to access, and PuUiam 
teaches that user specified search criteria are used to generate XML messages to locate 
available automobiles. 

He and Pulliam, both singly and in combination, fail to teach generating and 
sending, in response to receiving the advertisement request message, an advertisement 
request response message which includes a custom advertisement generated according to 
a portion of a service's capabilities that a client is allowed to access as indicated by a 
capability credential. Therefore, the rejection of claim 4 is not supported by the teachings 
of the cited art and withdrawal thereof is respectfully requested. 

Claims 5. 22. and 39 : 

Regarding claim 5, He in view of Pulliam does not teach or suggest a custom 
advertisement that specifies an XML schema definin2 messages to be sent by the client to 
the service and messages to be sent from the service to the client to use the portion of the 
service's capabilities. The portions cited by the Examiner (Pulliam, column 15, lines 39- 
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43 and column 16, lines 40-50) refer to the use of XML "to support application-to- 
application data exchange formats." In Pulliam, XML is used to describe the data 
content of messages, not to define the messages themselves. XML, as used by PuUiam, 
does not define messages to be sent by the client to the service nor messages to be sent 
from the service to the client to use the portion of the service's capabilities. 

In response to the above argument, the Examiner cites the same portions of 
PuUiam (column 15, lines 39-43, and column 16, lines 40-50) discussed above and refers 
to PuUiam's use of XML to send various messages. However, Pulliam does not mention 
an XML schema defining messages to be sent by the client to the service, nor does he 
describe messages to be sent from the service to the client. PuUiam's use of XML 
message to exchange data between applications does not include an XML schema 
defining messages. In fact, Pulliam describes the format of the messages used in his 
system (PuUiam, column 16, line 45 - column 17, line 29) implying that the messages are 
pre-defined. Pulliam teaches the use of pre-defined message and does not disclose using 
a XML schema defining the messages. Thus, PuUiam does not anticipate a custom 
advertisement specifying an XML schema defining messages. 

In the Response to Arguments section the Examiner argues that PuUiam's 
message client 924 provides functions to receive an XML formatted document and that 
generates and sends XML messages and application credentials to and firom the server. 
However, Pulliam only teaches generating XML message from user input specifying 
search criteria (Pulliam, column 15, lines 25-43). Pulliam does not mention an XML 
schema defining messages to be sent by the client to the service and messages to be sent 
from the service to the client. The Examiner also argues that in Pulliam search requests 
may be submitted in XML messages and the responses may be received in XML. 
However, using messages that contain XML does not imply the use of an XML Schema 
to define the messages themselves. 

The rejection of claim 5 is fiirther improper because the Examiner has not 
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explained how the cited teachings of Pulliam (the use of XML messages to submit search 
requests) appHes to He's system. The He reference fails to mention anything regarding 
XML messages, or search messages. Furthermore, the Examiner fails to explain how 
Pulliam suggests modifying He's system. The use of an XML schema in Pulliam to 
describe data to be exchanged in online shopping does not have any relevance to the 
access control ticket requests in He. Therefore, the combination of references is 
improper. 

Claims 13. 14, 30. 31 47 and 48 : 

He in view of Pulliam fails to teach wherein said access interface document 
comprises a schema defining messaRes for accessing said portion of the first service's 
capabilities, wherein said using the interface fi-om said access interface document to 
access a capability comprises sending a message according to said schema to the first 
service. 

The Examiner cites column 16, lines 40-50 of PuUiam and argues that using a pull 
down Ust to access available information/services teaches sending a message according a 
schema as part of using the interface from the access interface document to access a 
capability of a service. However, as argued above, pull down menus do not use or 
comprise a schema defining messages for accessing a portion of a service's capabilities. 
Instead, using a pull down menu only teaches making certain user selection. Also, 
Pulliam teaches that his pull down menus are used to specify search criteria. Pulliam 
does not teach that using his pull down menus comprises sending messages specified in a 
schema, as the Examiner suggests. 

Furthermore, the Examiner fails to explain how the cited teachings of Pulliam are 
combined with He's system. He's system does not include any need to specify search 
criteria as taught by PulUam. The Examiner has failed to provide any motivation for 
combining the online ordering system of Pulliam with the secure access method of He. 
Also, no combination of He and Pulliam results in a method wherein the access interface 
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document comprises a schema defining messages for accessing a portion of the first 
service's capabilities, wherein the using the interface from the access interface document 
to access a capability comprises sending a message according to the schema to the first 
service, as asserted by the Examiner. 

Claims 15, 32 and 49 : 

He in view of Pulliam fails to teach wherein said access interface document 
comprises a message schema defining messages for accessing the portion of the first 
service's capabilities, wherein said using the interface from the access interface document 
to access a capability comprises the client using the access interface document to 
construct a message gate for sending messages to the first service, wherein the message 
gate embeds the capability credential in each message . 

The Examiner states, "Pulliam' s message client 924 provides the required 
functions to receive the XML formatted document, then generates and sends the XML 
messages and application credentials to and from the server" and cites column 15, lines 
38-43 of Pulliam. However, Pulliam's teachings do not disclose an access interface 
document comprising a message schema defining messages for accessing a portion of a 
service's capabilities. The Examiner has also argued, regarding claim 1, that He's pull- 
down menus (of network elements) is an access interface document. However, the 
Examiner has failed to point out any passage of He or Pulliam that discloses wherein the 
pull-down menus comprise a message schema defining messages, as recited in claim 15. 
hi fact, neither He nor PulUam ever mention any sort of access interface document 
comprising a message schema defining messages for accessing a portion of a service's 
capabilities. 

Furthermore, the cited passage of Pulliam does not teach a message that embeds 
the capability credential in each message. Instead, the cited passage only describes how 
Pulliam's message client 924 provides sends and receives XML messages and application 
credentials to and from the locate server. Nowhere does Pulliam mention a message gate 
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embedding a capability credential in each message. The Examiner is merely speculating 
in hindsight regarding the embedding of a capability credential with every message. 

Claims 16, 33 and 50 : 

Regarding claim 16, He in view of PuUiam fails to teach wherein the message gate 
checks each message for comphance with the message schema . The Examiner cites 
column 16, lines 40 - 50 of He. However, the cited portion of He, only describes He's 
use of a registration database and how He's authentication server 202 maintains a 
database of user account records. The cited passage has no relevance on a message gate 
that checks each message for compliance with a message schema. He does not teach 
anything regarding a message gate that checks each message for compliance with a 
message schema, as recited in claim 16. As argued above, He in view of PuUiam fails to 
disclose a message schema defining messages to access a portion of a service's 
capabilities (please refer to the arguments presented above regarding claim 5). 

Thus, He in view of Pulliam fails to teach wherein the message gate checks each 
message for compliance with the message schema. 

Claims 17, 34 and 51 ; 

He in view of Pulliam fails to teach wherein the message schema is an XML 
schema. The Examiner only cites column 16, lines 40- 50 of He. However, the cited 
portion of He (column 16, lines 40-50), only describes He's use of a registration database 
and how He's authentication server 202 maintains a database of user account records. 
The cited passage does not mention anything regarding a message schema or an XML 
schema. Pulliam does teach the use of messages containing XML, but fails to teach an 
XML message schema, as recited in claim 17. Please refer to the arguments above 
regarding claim 15 for a more detailed argument regarding Pulliam's failure to disclose 
such a message schema. 
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Claim 21: 



Regarding claim 21, He in view of Pulliam fails to teach an interface configured 
to receive an advertisement request response message including a custom advertisement , 
wherein said custom advertisement is generated according to the portion of the first 
service's capabilities that the capabilitv credential indicates the cHent is allowed to 
access. 

The Examiner states, "generating pull-down menus to identify those capabilities 
to which the client is allowed to access" (emphasis added) citing He, column 26, lines 58- 
65 and Pulliam, column 13, lines 34-40), However, the pull-down menus in He and 
Pulliam referred to by the Examiner have nothing to do with generating a custom 
advertisement as the access interface document according to the portion of the service's 
capabilities that the capability credential indicates the client is allowed to access. He's 
pull down menus "identify those network elements to which [the user] is allowed access." 
The cited section of Pulliam pertains to "pull-down lists of available makes and models" 
which may be used to select "preferences" for "matching vehicles" as described above 
regarding claim 2. PuUiam's teachings have nothing to do with generating a custom 
advertisement according to a portion of a service's capabilities. 

Furthermore, the Examiner refers to He's and PuUiam's pull-down menus as 
identifying capabilities. He, however, does not teach using pull-down menus to identify 
capabilities, but instead uses pull-down menus to identify those specific network elements 
with which a user may communicate (He, column 26, lines 58-65), not any particular 
capabilities or portions of the capabilities of a service that a user may access. Similarly, 
Pulliam never describes pull-down menus as identifying service capabilities. Instead, 
Pulliam uses pull-down lists as one example of collected search criteria from a user 
(PuUiam, column 13, lines 34-37). The Examiner is clearly applying his own speculation 
to the teachings of He and Pulliam. 
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Appellants submit that He and Pulliam, both singly and in combination, fail to 
teach generating and sending, in response to receiving the advertisement request message, 
an advertisement request response message which includes a custom advertisement 
generated according to a portion of a service's capabilities that a client is allowed to 
access as indicated by a capability credential. Therefore, the rejection of claim 4 is not 
supported by the teachings of the cited art and withdrawal thereof is respectfully 
requested. 

Claim 38 : 

He in view of PuUiam fails to teach receiving, in an advertisement request 
response message, a custom advertisement in response to sending said advertisement 
request message, wherein said custom advertisement is generated according to said 
portion of the first service's capabilities that said capabilitv credential indicates the client 
is allowed to access 

The Examiner asserts that, "the server generating pull-down menus to identify 
those capabilities to which the client is allowed to access" (emphasis added) citing He, 
column 26, lines 58-65 and PuUiam, column 13, lines 34-40). However, the pull-down 
menus in He and PuUiam referred to by the Examiner have nothing to do with generating 
a custom advertisement as the access interface document according to the portion of the 
service's capabilities that the capability credential indicates the client is allowed to 
access. He's pull down menus "identify those network elements to which [the user] is 
allowed access." The cited section of PuUiam pertains to "pull-down lists of available 
makes and models" which may be used to select "preferences" for "matching vehicles" as 
described above regarding claim 2. PuUiam' s teachings have nothing to do with 
generating a custom advertisement according to a portion of a service's capabilities. 

Furthermore, the Examiner refers to He's and PuUiam' s pull-down menus as 
identifying capabilities. He, however, does not teach using pull-down menus to identify 
capabilities, but instead uses pull-down menus to identify those specific network 



09/653,610 (5181-70500/P5201) 



22 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



elements with which a user may communicate (He, column 26, lines 58-65), not any 
particular capabilities or portions of the capabilities of a service that a user may access. 
Similarly, PuUiam never describes pull-down menus as identifying service capabilities. 
Instead, PuUiam uses pull-down Usts as one example of collected search criteria from a 
user (Pulliam, column 13, lines 34-37). The Examiner is clearly applying his own 
speculation to the teachings of He and Pulliam. 

Appellants submit that He and Pulliam, both singly and in combination, fail to 
teach generating and sending, in response to receiving the advertisement request message, 
an advertisement request response message which includes a custom advertisement 
generated according to a portion of a service's capabilities that a client is allowed to 
access as indicated by a capability credential. Therefore, the rejection of claim 4 is not 
supported by the teachings of the cited art and withdrawal thereof is respectfully 
requested. 

VIIL CONCLUSION 

For the foregoing reasons, it is submitted that the Examiner's rejection of claims 
1-5, 13-22, 30-39 and 47-51 was erroneous, and reversal of his decision is respectfully 
requested. 

The Commissioner is authorized to charge the appeal brief fee of $500.00 and any 
other fees that may be due to Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit 
Account No. 501505/5181-70500/RCK. This Appeal Brief is submitted with a return 
receipt postcard. 



Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 
Attorney for Appellants 
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IX. CLAIMS APPENDIX 



The claims on appeal are as follows. 

1. A method for accessing a service in a distributed computing environment, 
comprising: 

a client receiving a capability credential, v^herein said capability credential 
indicates that the client is allov^ed to access a portion of a first service's 
capabilities; 

the client using said capability credential to request an access interface document 
to access the first service; 

the client receiving said access interface document, v^herein said access interface 
document comprises an interface for accessing only said portion of the 
first service's capabilities; and 

the client using the interface from said access interface document to access a 
capability from said portion of the first service's capabilities. 

2. The method as recited in claim 1, wherein said using said capability 
credential to request an access interface document comprises sending an advertisement 
request message in a data representation language, wherein said advertisement request 
message includes said capability credential. 

3. The method as recited in claim 2, wherein said data representation 
language is extensible Markup Language (XML). 

4. The method as recited in claim 2, further comprising: 
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generating a custom advertisement in response to receiving said advertisement 
request message, said custom advertisement is generated according to said 
portion of the first service's capabilities that said capabiUty credential 
indicates the client is allowed to access; and 

sending an advertisement request response message to the client, wherein said 
advertisement request response message includes said custom 
advertisement as said access interface document. 

5. The method as recited in claim 4, wherein said custom advertisement 
specifies an XML schema defining messages to be sent by the client to the first service 
and messages to be sent from the first service to the client to use said portion of the first 
service's capabilities. 

13. The method as recited in claim 1, wherein said access interface document 
comprises a schema defining messages for accessing said portion of the first service's 
capabilities, wherein said using the interface from said access interface document to 
access a capability comprises sending a message according to said schema to the first 
service. 

14. The method as recited in claim 13, wherein said message includes said 
capability credential, the method fiirther comprising the first service using said capability 
credential to authenticate said message as from the client. 

15. The method as recited in claim 1, wherein said access interface document 
comprises a message schema defining messages for accessing said portion of the first 
service's capabilities, wherein said using the interface from said access interface 
document to access a capability comprises the client using said access interface document 
to construct a message gate for sending messages to the first service, wherein the message 
gate embeds said capability credential in each message. 
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16. The method as recited in claim 15, wherein the message gate checks each 
message for compUance with said message schema. 

17. The method as recited in claim 16, wherein said message schema is an 
XML schema. 

18. A cUent device, comprising: 

a connection to a distributed computing environment; 

an interface coupled to said connection and configured to receive over the 
connection a capabiUty credential, wherein said capability credential 
indicates that a client on the client device is allowed to access a portion of 
a first service's capabilities; 

wherein the interface is further configured to use said capability credential to 
request an access interface document to access the first service; 

wherein the interface is fiirther configured to receive said access interface 
document over the connection, wherein said access interface document 
comprises an information for accessing only said portion of the first 
service's capabilities; and 

wherein the interface is fiirther configured to use the information fi-om said access 
interface document to access over the connection a capability from said 
portion of the first service's capabilities. 

19. The cUent device as recited in claim 18, wherein the interface is 
configured to use said capability credential to request an access interface document by 
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sending an advertisement request message in a data representation language, wherein said 
advertisement request message includes said capability credential. 

20. The client device as recited in claim 19, wherein said data representation 
language is extensible Markup Language (XML). 

21. The cUent device as recited in claim 19, wherein the interface is further 
configured to receive an advertisement request response message including a custom 
advertisement, wherein said custom advertisement is generated according to said portion 
of the first service's capabilities that said capability credential indicates the client is 
allowed to access. 

22. The client device as recited in claim 21, wherein said custom 
advertisement specifies an XML schema defining messages to be sent by the client to the 
first service and messages to be sent fi:'om the first service to the client to use said portion 
of the first service's capabilities. 

30. The client device as recited in claim 18, wherein said access interface 
document comprises a schema defining messages for accessing said portion of the first 
service's capabilities, wherein the interface is configured to use the information from said 
access interface document to access a capability by sending a message according to said 
schema to the first service. 

31. The client device as recited in claim 30, wherein said message includes 
said capability credential so that the first service may use said capability credential to 
authenticate said message as fi"om the chent. 

32. The client device as recited in claim 18, wherein said access interface 
document comprises a message schema defining messages for accessing said portion of 
the first service's capabilities, wherein the interface is configured to use the information 
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from said access interface document to access a capability by using said access interface 
document to construct a message gate in the client device for sending messages to the 
first service, wherein the message gate embeds said capability credential in each message. 

33. The client device as recited in claim 32, wherein the message gate is 
configured to check each message for compliance with said message schema. 

34. The client device as recited in claim 33, wherein said message schema is 
an XML schema. 

35. A carrier medium comprising program instructions, wherein the program 
instructions are computer-executable on a client device to implement: 

receiving a capability credential, wherein said capability credential indicates that a 
client within the client device is allowed to access a portion of a first 
service's capabilities; 

using said capability credential to request an access interface document to access 
the first service; 

receiving said access interface document, wherein said access interface document 
comprises an interface for accessing only said portion of the first service's 
capabilities; and 

using the interface from said access interface document to access a capability from 
said portion of the first service's capabilities. 

36. The carrier medium as recited in claim 35, wherein said using said 
capability credential to request an access interface document comprises sending an 
advertisement request message in a data representation language, wherein said 
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advertisement request message includes said capability credential 

37. The carrier medium as recited in claim 36, wherein said data 
representation language is extensible Markup Language (XML). 

38. The carrier medium as recited in claim 36, wherein the program 
instructions are computer-executable on the client device to further implement: 

receiving, in an advertisement request response message, a custom advertisement 
in response to sending said advertisement request message, wherein said 
custom advertisement is generated according to said portion of the first 
service's capabilities that said capability credential indicates the client is 
allowed to access. 

39. The carrier medium as recited in claim 38, wherein said custom 
advertisement specifies an XML schema defining messages to be sent by the client to the 
first service and messages to be sent fi-om the first service to the client to use said portion 
of the first service's capabilities. 

47. The carrier medium as recited in claim 35, wherein said access interface 
document comprises a schema defining messages for accessing said portion of the first 
service's capabilities, wherein said using the interface fi:*om said access interface 
document to access a capability comprises sending a message according to said schema to 
the first service. 

48. The carrier medium as recited in claim 47, wherein said message includes 
said capability credential so that the first service may use said capability credential to 
authenticate said message as fi*om the client. 

49. The carrier medium as recited in claim 35, wherein said access interface 
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document comprises a message schema defining messages for accessing said portion of 
the first service's capabilities, wherein said using the interface from said access interface 
document to access a capability comprises the client using said access interface document 
to construct a message gate for sending messages to the first service, wherein the message 
gate embeds said capability credential in each message. 

50. The carrier medium as recited in claim 49, wherein the program 
instructions are computer-executable on the client device to further implement the 
message gate checking each message for compliance with said message schema. 

51. The carrier medium as recited in claim 50, wherein said message schema 
is an XML schema. 
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X. EVIDENCE APPENDIX 

No evidence submitted under 37 CFR §§ 1.130, 1.131 or 1.132 or otherwise 
entered by the Examiner is relied upon in this appeal. 
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XI. RELATED PROCEEDINGS APPENDIX 

There are no related proceedings. 
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